This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The Open Mobile Alliance (OMA) currently specifies an Instant Messaging service, namely OMA SIP/SIMPLE IM 1.0. The service is based on an Internet Engineering Task Force (IETF)-specified Session Initiation Protocol (SIP)/SIMPLE protocol such as (Session Initiation Protocol) SIP, Message Session Relay Protocol (MSRP) and Extensible Markup Language (XML) Configuration Application Protocol (XCAP).
The SIP events framework defines general mechanisms for subscribing to and receiving notifications of events within SIP networks. The SIP events framework is defined in the IETF Request for Comments (RFC) 3265, which can be found at www.ietf.org/rfc/rfc3265.txt and is incorporated herein by reference in its entirety. SIP introduces a package which is a specific “instantiation” of the events framework for a well-defined set of events. As used herein, a “SIP event package” is used for tightly coupled conferences. The SIP event package can be used by a conference notification service as outlined in the SIP conferencing framework.
In multimedia conferencing, participants of the conference use SIP to subscribe to the conference event package and to obtain information about, among other things, the list of participants, as well as their properties in the conference and the state of other components of the conference. This is discussed in detail in the IETF RFC 4575, which can be found at www.ietf.org/rfc/rfc4575.txt and is incorporated herein by reference in its entirety. The body of notification in this conference event package is a XML document. The document describes the state of the conference, the list of participants in the conference, their status, information, media types, etc.
A user becomes a participant of a conference by first sending a SIP INVITE request to the Uniform Resource Identifier (URI) that has been allocated to the conference. The conference server answers with a 200 OK response to accept the new participant. The new participant then subscribes to the conference event package in order to obtain the roster and other associated conference data. At about the same time, the other participants who are subscribed to the conference are also notified about the new participant. This is accomplished with an updated notification carrying the XML conference document.
Conference servers typically provide an anonymization function at the user's disposal. In many situations, a participant may wish to remain anonymous to the other conference participants, i.e., he or she may not want his or her SIP URI to be revealed to the other participants. This is achieved with the anonymization function of the conference, which replaces the participant's real SIP URI with an anonymous SIP URI such as sip:user@anonymous.invalid. This is the current practice according the IETF RFC 3261, which can be found at www.ietf.org/rfc/rfc3261.txt and is incorporated herein by reference in its entirety. The anonymization function in the conference therefore allows the conference application to authenticate users and know the real SIP URI of a user, without having to reveal this information to the rest of the participants in the conference.
In conventional conference scenarios, a problem arises when several anonymous users join the same conference. In particular, when there are several anonymous participants, each anonymous participant is currently unable to identify the anonymous URI that the conference server has selected for him or her. For example, it is helpful to envision a scenario where, in a given conference, there are 50 participants, and 10 of these participants have chosen to remain anonymous. In this situation, it is helpful to assume that the anonymous URIs allocated by the conference server contain some random number, for example, sip:user39@anonymous.invalid, sip:user1932@anonymous.invalid, sip:user2723@anonymous.invalid, and so on. At some point in time, a new participant joins the conference, thereby becoming the 11th anonymous participant out of a total of 51 participants. This new participant also subscribes to the conference event package and obtains a list of participants, which includes also his own anonymous URI: sip:user4563@anonymous.invalid. The problem is that this new participant is not able to distinguish himself from the rest of the other anonymous participants.
In light of the above, it is particularly desirable for the relevant software (the SIP User Agent) in any participant's device to be able to distinguish his or her own SIP URI from others, for example, to display private messages that are received through the conference server. It is desirable for the user interface (UI) in the SIP application to provide a differentiation of these private messages that are sent by the other participants to the allocated anonymous URI. Therefore, the SIP User Agent (UA) needs to know which URI, among all of the anonymous URIs, is the anonymous URI that is allocated to the user.